Along with the increasing dependence of society, economy, and living on on-line services, identity management for managing information regarding individuals and organizations is becoming increasingly important. Identity management is a technique that facilitates security and convenience of information regarding individuals and organizations in various services and systems and manages the whole life cycle of an identity from registration to changes and deletion.
Here, the term identity relates to all information that specifies an individual, a group, or an organization/company under certain circumstances, and includes an identifier, credentials, and attributes. The identifier is information to identify the identity, and corresponds to an account or an employee number. The credentials are information that indicates the properness of certain information contents, and are, for example, a password. The attributes are information that characterizes the identity, and indicate, for example, a name, an address, and date of birth.
Single sign-on (hereinafter abbreviated as SSO) is known as an example of a technique that uses such identity management. The SSO is a technique that allows a plurality of applications and services to be used by one authentication procedure. In many cases, the SSO integrates authentications provided in a plurality of applications in a single domain such as an intranet at one company. In this case, the SSO is generally enabled by a method that includes an authentication result in a HTTP cookie so that the authentication result is shared among the applications. Such SSO methods have been independently manufactured by system integration (SI) vendors or middleware vendors as access management products.
Recently, there has been a demand for a SSO among different domains (hereinafter also referred to as cross domains) across the single domain. This is attributed to outsourcing resulting from, for example, the integration or merger of companies, overseas expansion, and software as a service (SaaS) in emerging cloud computing. For example, one advantage of SaaS is its on-demand availability.
However, there have been many problems in sharing an authentication result in the case of cross-domain SSO. There are two main reasons for this. One reason is that the use of the HTTP cookie is limited to the single domain so that an authentication result cannot be shared among domains by the use of the HTTP cookie. The other reason is that the SSO method of an access management product used for each domain varies among vendors so that the simple introduction of the method is impossible and additional measures need to be prepared.
There has been an increasing demand for the standardization of the SSO to solve the aforementioned problems. One example of a standard technique that meets the demand is a security assertion markup language (SAML) developed by a non-profit organization called Organization for the Advancement of Structured Information Standards (OASIS).
SAML is a specification that defines how information regarding authentication, approval, and attributes as well as transmission/receiving procedures is expressed, and is systematically prescribed to enable various package forms depending on purposes. A main body comprises three parts: an identity provider (hereinafter abbreviated as IdP and referred to as an ID provider), a service provider (hereinafter abbreviated as SP and referred to as a service provider), and a user. The service provider trusts an authentication result issued by the ID provider to enable the SSO.
In general, the following two points need to be considered to start SSO based on SAML. The first point is to build a circle of trust through information exchanges and consensus building in business and technical aspects between the service provider and the ID provider. The second point is that one user has an individual account for each service provider and these individual SP accounts are previously federated with the account of the ID provider. The SSO cannot be started before the building of a circle of trust and the previous account federation are prepared.
After these preparations, the SSO is enabled by the following procedures (1) to (6). Here, the procedures for the SSO performed through a Web browser are described.
(1) The user requests the provision of a service from the service provider.
(2) As the service provider has not yet authenticated the user, an authentication request is transmitted to the ID provider via the Web browser of the user.
(3) The ID provider authenticates the user by some means, and creates an authentication assertion. SAML does not define the authentication means, and defines a system that conveys the authentication assertion to the service provider. The authentication assertion includes information on the kind of authentication means and on how credentials are created, in order for the service provider to judge whether an authentication result can be trusted.
(4) The ID provider returns the authentication result including the created authentication assertion to the service provider via the Web browser of the user.
(5) The service provider determines whether to provide the service in accordance with the authentication result from the ID provider.
(6) The user receives the provision of the service from the service provider.
Thus, the SSO based on the SAML allows the user to use a plurality of services by one authentication procedure in the ID provider without additional authentication procedures. At present, to ensure cross-domain interoperability, the middleware vendors which have packaged the individual SSO method carry out the sale of access management products in which an ID provider/service provider function of the SAML is packaged, and the application to business Web services in which the service provider function of the SAML is packaged.
The SSO based on the SAML is only the “use” of the identity which is a part of the whole life cycle of the identity. As described above, when the SSO is started, accounts need to be federated. For the account federation, a technique is required to comprehensively federate the management of the registration, changes, deletion, reissuance, and suspension of the identity between the service provider and the ID provider.
Account provisioning is known as a technique to automate the registration, changes, deletion, reissuance, and suspension of the identity. One such standard technique is a service provisioning markup language (SPML).
In the meantime, there is known a data processing system which dynamically conducts account federation as a part of the SSO from the condition in which the aforementioned account federation is not prepared. In general, an error occurs if the SSO is started without any account of the user registered in the service provider, that is, without account federation.
However, this data processing system can dynamically conduct account federation as a part of the SSO even in the aforementioned condition. Specifically, after the service provider has received a service request from the user, it is checked as to whether the service provider has information sufficient to register the account of the user. After the check, the service provider requests user attributes from the ID provider, and the ID provider provides the desired user attributes to the service provider. Accordingly, the data processing system registers and federates the accounts in the SSO process.
The data processing system described above has no problem in general because the processing demands in requesting and providing user attributes necessary for the registration of the accounts of the individual users are light, and a large volume of previous processing for a large number of users is not required.
However, according to the examination by the present inventor, there is room for improvement, as described below.
When a company uses a service provided by the service provider, an information system (IS) department generally performs account registration and federation for the service provider.
The IS department collectively performs a large volume of previous processing for a large number of users belonging to the company, or conducts a procedure through a flow of approval in accordance with a timing given by a user and then registers and federates the account of the user.
Here, the former previous processing does not require account registration and federation in the process of the SSO, and has therefore no relation to the data processing system.
On the other hand, the latter approval flow is conducted not only through the user but also through many people, including the superior in each layer of the organizational hierarchy to which the user belongs and people in procurement and IS departments. This requires much time and effort. Moreover, the IS department does not collectively perform the previous processing, leading to manual operations that are burdensome, inefficient, and inconvenient. For example, it is not possible to take advantage of the readily available SaaS.
It is therefore preferable that the system which performs account registration and federation in the process of the SSO comprises a seamless structure that determines whether to permit service use in a nonmanual manner.
It is an object of the present invention to provide an authentication federation system and an ID provider device capable of determining whether to permit service use in a nonmanual manner when performing account registration and federation in the process of the SSO.